状況で重要度が変わるGuardDutyイベントを確認してみた

こんにちは。たかやまです。

GuardDutyのイベントには、検索状況によって重要度が変わるイベントがあります。

アスタリスク (*) が付いている重要度は、その検索の状況によって重要度が異なるものを示しています。

重要度が変わるイベントが実際にどのような状況で変わるのか気になったので確認してみました。

• UnauthorizedAccess:EC2/RDPBruteForce
• UnauthorizedAccess:EC2/SSHBruteForce
• Impact:EC2/WinRMBruteForce
• UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.InsideAWS
• Recon:EC2/PortProbeUnprotectedPort
• Exfiltration:S3/ObjectRead.Unusual

EC2/BruteForce

• UnauthorizedAccess:EC2/RDPBruteForce
• UnauthorizedAccess:EC2/SSHBruteForce
• Impact:EC2/WinRMBruteForce

BruteForce関係のイベントは攻撃者か攻撃対象かで重要度が変わります。

重要度	概要
高	BruteForceを行う攻撃者となっている場合
低	BruteForceの攻撃対象となっている場合

検証

AWSから提供されているamazon-guardduty-testerを使うことでRDPとSSHのBruteForce攻撃を起こすことが可能です。詳しい使い方はこちらのブログをご確認ください。

CloudFormationを起動すると以下のように攻撃者インスタンスと攻撃対象インスタンスが作成されます。

手順の通り攻撃者インスタンス内にあるguardduty_tester.shを実行するとSSH/RDPのBruteForce攻撃のイベントがGuardDutyに記録されます。

このとき、攻撃者インスタンスと攻撃対象インスタンスでイベントの重要度が違うことが確認できると思います。

対応と対策

では、実際にイベントを検知した場合の対応として重要度別に以下の対応が考えられます。

重要度高 : 攻撃者となっている場合

サーバが侵害されている可能性が高いため、直ちに対応が必要となります。

1. セキュリティグループのIN/OUT閉鎖
2. 今後の調査に向けて停止を伴わないAMIの取得。(メモリ情報を取得するため)
3. インスタンスの停止、削除等

重要度低 : 攻撃対象となっている場合

侵害の可能性は低いですが、外部から接続を試みられていることを念頭に対応を検討します。

1. 意図しない接続の場合にはセキュリティグループ/ネットワークACLをただしい接続先に設定する。
2. 攻撃対象にならないための対処を行う
   • パスワード認証を利用しない
   • SSH/RDP/WinRMのポートを開けずに、SSMセッションマネージャで接続する

Tips

amazon-guardduty-testerの攻撃者インスタンスでRDPブルートフォースを行った際に以下のエラーが出る場合、必要なパッケージをインストールして再コンパイルする必要がありました。

[ERROR] Compiled without FREERDP2 support, module not available!

yum install freerdp-devel
cd /home/ec2-user/thc-hydra
make clean
./configure
make
make install

参考 : I have error with [ERROR] Compiled without FREERDP2 support, module not available! #420

IAMUser/InstanceCredentialExfiltration.InsideAWS

このイベントはEC2内の認証情報が流出し、別のAWSアカウントで利用された場合記録されます。
重要度が変わる条件として流出先が関連性のあるアカウントかそうでないかです。

重要度	概要
高	関連性のないアカウントからのAPIアクセス
中	関連性のあるアカウントからのAPIアクセス

この関連性の定義ですが、What's newの記載を見る限りGuardDutyマルチアカウント設定やTrasit Gatewayを使っている場合にGuardDutyは関連性があるアカウントとして扱うようです。

What's new

検証

GuardDutyマルチアカウント設定を行っているアカウントとそうでない外部アカウントでAPI接続を試してみます。

アカウント(560)に対してGuardDutyマルチアカウント設定を行い関連性のあるアカウントにします。

流出アカウント(601)で起動しているEC2インスタンスの認証情報を取り出します。

cat << END

export AWS_ACCESS_KEY_ID=`mu=http://169.254.169.254/latest/meta-data/iam/security-credentials/;curl -s $mu | echo $mu$(cat) | xargs -n1 curl -s | jq -r '.AccessKeyId'`
export AWS_SECRET_ACCESS_KEY=`mu=http://169.254.169.254/latest/meta-data/iam/security-credentials/;curl -s $mu | echo $mu$(cat) | xargs -n1 curl -s | jq -r '.SecretAccessKey'`
export AWS_SESSION_TOKEN=`mu=http://169.254.169.254/latest/meta-data/iam/security-credentials/;curl -s $mu | echo $mu$(cat) | xargs -n1 curl -s | jq -r '.Token'`

END

取り出した認証情報を関連性のあるアカウント(560)と関連性のないアカウント(585)に起動しているEC2インスタンスに情報を登録します。 登録後、S3コマンドを実行し認証情報を取り出したアカウントへアクセスします。

export AWS_ACCESS_KEY_ID=xxxxxxxxxxxxxxxxxxxxx
export AWS_SECRET_ACCESS_KEY=xxxxxxxxxxxxxxxxxxxxx
export AWS_SESSION_TOKEN=xxxxxxxxxxxxxxxxxxxxx
aws s3 ls

数分後、流出アカウント(601)のGuardDutyに重要度の異なるイベントが記録されていることが確認できます。

対応と対策

こちらのブログの暫定対処と封じ込め・再発防止が参考になります！

EC2/PortProbeUnprotectedPort

このイベントはスキャンされるポートによって重要度が変わってきます。
特にElasticsearchが利用するポート9200/9300がスキャンされる場合には重要度が高く設定されています。

重要度	概要
高	既知の悪意あるホストにポート9200/9300(Elasticsearch)をスキャンされている
低	既知の悪意あるホストにポートスキャンされている

検証

重要度高のイベントは検知できませんでしたが、過去の検証ブログが検知方法の参考になります。

対応と対策

こちらのイベントもBruteForceの対策と同様、セキュリティグループ/ネットワークACLの見直しが有効な対策となります。

S3/ObjectRead.Unusual

こちらのイベントは過去のS3 API履歴をもとに作られたベースラインから逸脱する異常なAPI呼び出しが行われた場合に記録されます。

EC2内の認証情報を利用して異常なAPI呼び出しを行っている場合には重要度が高となります。

重要度	概要
高	EC2内の認証情報を利用して異常なS3 API呼び出しを行っている
中	IAMエンティティが過去の履歴にないS3 APIの呼び出し方を行っていたり、異常な場所から呼び出している

検証

過去のAPI履歴が足りないのか、うまくイベント発生ができませんでした。。
時間がたってから再度検証してみたいと思います。

対応と対策

1. 不正に利用が疑われる場合はIAMのセッション取り消し
2. アクセスされたS3バケットのポリシー確認
3. CloudTrailでS3データイベントを確認
   • S3データイベントは事前に有効化している必要あり

まとめ

ドキュメント通り、状況に合わせてよしなに重要度を変更してくれることがわかりました。
実際に攻撃を行いGuardDutyを検知させることでイベントへの理解も深まった気がします。
気になるイベントがあればまた手を動かしてみたいと思います。

以上、たかやまでした。